REMARKS/ARGUMENTS 

The rejections presented in the Office action dated December 17, 2004 have been 
considered. Claims 1-39 remain pending in the application. The allowability of Claim 36 
is acknowledged, and the Applicant thanks the Examiner for favorable consideration of this 
claim. Reconsideration of the remaining pending claims and allowance of the application in 
view of the present response is respectfully requested. 

Claims 1-3, 8-31, 33-35, 38, and 39 stand rejected under 35 U.S.C. §102(e) as being 
anticipated by U.S. Publication No. 2003/0013434 to Rosenberg et al. (hereinafter 
Rosenberg). Applicants respectfully traverse the rejection. To anticipate a claim the 
reference must teach every element of the claim, and it is respectfully submitted that 
Rosenberg does not meet this standard. 

"A claim is anticipated only if each and every element as set forth in the claim is 
found, either expressly or inherently described, in a single prior art reference." MPEP 2131, 
quoting Verdegaal Bros. v. Union Oil Co, of California, 2 USPQ2d 1051, 1053 (Fed. Cir. 
1987). "The identical invention must be shown in as complete detail as is contained in the 
patent claim; /.e. every element of the claimed invention must be literally present, arranged 
as in the claim." MPEP 2131, quoting Richardson v. Suzuki Motor Co., 9 USPQ2d 1913, 
1920 (Fed. Cir, 1989). The Applicant submits that Rosenberg does not teach every element 
of independent Claims 1, 21, 24, 38, and 39, and therefore fails to anticipate Claims 1,21, 
24, 38, and 39. 

Independent Claims 1, 21, 24, 38, and 39 are directed to provisioning a mobile 
terminal by a provisioning Web service for use by a network service application provided 
by the network service. Provisioning includes configuring the mobile terminal for use of 
the application and delivering the application to the mobile terminal. It is first pointed out 
that Rosenberg is directed to a Web browser interface used to replace the actions formerly 
required by a human customer service representative [0014]. The mobile user maneuvers to 
a provider Web page and fills in data forms [0022]. In response, the user is provided with 
an activation code that contains the provisioning data, such as IP address and preferences 
[0027]. Then the user "enters the activation code into a window provided by the activation 
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module on the device's screen. The activation module decodes the activation code back into 
the IP address and side preference and programs them into the wireless modem's memory, 
thereby activating the wireless services on the wireless device." [0027]. Thus, Rosenberg 
does not teach provisioning the terminal via a provisioning Web service, because Rosenberg 
clearly teaches provisioning the terminal manually. 

The Applicant respectfully submits that Web services is a specific term of art, and 
the fact that data may be accessed via the Web does not necessarily suggest that Web 
services are involved in providing that data. In particular, accessing a document from a Web 
site does not necessary imply that a Web service is being invoked. A Web service generally 
refers to a self-contained modular application that can be published in a ready-to-use 
format, located, and invoked across the World Wide Web. When a Web service is 
deployed, other applications and Web services can locate and invoke the deployed service 
(see, e.g., Specification page 10, lines 10-21). \n Rosenberg, an application is not invoked 
across the Web to provision the terminal; a Web document is merely accessed by the user 
via a browser to display an activation code. Rosenberg does not even describe the use of 
Web services to generate or access the user account documents, much less to provision the 
terminal. Even assuming arguendo that the browser accesses the Web docxmient via Web 
services, the browser does not provision the terminal. Terminal configuration in Rosenberg 
is performed by the activation module (see. ref no. 57 in FIG. 4) 

In Rosenberg a browser is used only to retrieve user account documents, and neither 
the browser or any other component in Rosenberg invoke Web services to provision the 
terminal. The provisioning in Rosenberg is accomplished by a user typing in an activation 
code into an activation module that is running locally on the device (see, e.g., [0060]). The 
activation module as described in Rosenberg has a local user interface (e.g., "a window 
provided by activation module 46 on the screen of wireless device" and "typing the 
activation code," [0060]), and Rosenberg does not disclose or otherwise suggest the 
activation module can interface with Web Services via the network to provision the 
terminal. As a result, Rosenberg merely teaches manual configuration of a terminal by a 
user who accesses a locally running process. Rosenberg does not teach provisioning the 
terminal by a provisioning Web service, therefore Rosenberg does not teach each and every 
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element of Claims 1,21, 24, 38, and 39. Applicants submit, then, that Claims 1, 21, 24, 38, 
and 39 are in condition for allowance. 

Dependent Claims 2-3, 8-20, 22-23, 25-31, and 33-35 are dependent from 
independent Claims 1,21, and 24, respectively and also stand rejected under 35 U.S.C. 
§ 102(e) as being anticipated by Rosenberg, While Applicant does not acquiesce with the 
particular rejections to these dependent claims, these rejections are now moot in view of the 
remarks made in connection with independent Claims 1,21, and 24. These dependent 
claims include all of the limitations of the base claim and any intervening claims, and recite 
additional features which further distinguish these claims from the cited references. 
Therefore, dependent Claims 2-3, 8-20, 22-23, 25-31, and 33-35 are also in condition for 
allowance. 

Claims 4-7 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Rosenberg in view of Scott Seely "Web Service description and Discovery Using UDDI, 
Part II", Microsoft Corporation (hereinafter Seely). Applicants respectfiiUy traverse the 
rejection. 

According to MPEP §2142, to establish a prima facie case of obviousness under 35 
U.S.C. §103: 

1) there must be some suggestion or motivation either in the references 
themselves or in the knowledge generally available to one of ordinary skill in the art, 
to modify the reference or to combine reference teachings; 

2) there must be a reasonable expectation of success; and 

3) the prior art reference (or references when combined) must teach or 
suggest all the claim limitations. 

The Applicant respectfully submits that the combination of Rosenberg in view of 
Seely does not teach or suggest all of the limitations of Claims 4-7. Further, the Applicant 
respectfully submits that there is no motivation to combine the reference teachings as 
suggested in the Office Action. 

Dependent Claims 4-7 depend from independent Claim 1, and include all of the 
limitations of the base claim and any intervening claims, and recite additional features 
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which further distinguish these claims from the cited references. As argued in greater detail 
above, Rosenberg at least fails to teach provisioning a mobile terminal by a provisioning 
Web service, because Rosenberg teaches provisioning the terminal manually. Thus 
Rosenberg fails to anticipate independent Claim 1, and as a result fails to anticipate Claims 
4-7. Seely fails to cure the deficiencies of Rosenberg, Seely merely teaches the basics of 
UDDI description and discovery, and does not teach or suggest any aspects of provisioning 
mobile devices. Therefore, the combination of Rosenberg and Seely fail to teach or suggest 
provisioning a mobile terminal by a provisioning Web service, and thus a prima facie case 
of obviousness has not been established. 

In addition, there is no motivation to combine the Rosenberg and Seely as suggested 
in the Office Action. Neither Rosenberg nor Seely provides motivation to use Web services 
to provision a mobile terminal. Rosenberg teaches providing activation data to users via a 
Web page, and the user then enters the activation data into a locally running process. The 
use of Web services would provide no noticeable improvement to the techniques taught 
Rosenberg, because Rosenberg merely teaches the graphical presentation of an activation 
code to the user in a browser. Such graphical representations of data in a browser are well 
known in the art, and can be easily accomplished without the use of Web services, e.g., 
through the use of static or dynamic Web documents. In addition, the activation module in 
Rosenberg uses a local user interface and is not disclosed as having any network interface. 
Thus, there is no suggestion or motivation in Rosenberg to modify an activation module to 
provision a terminal via a network using Web services. 

Seely teaches some basic implementation details of registering a Web service with a 
UDDI directory. In particular, Seely illustrates an example of implementing a "Logon" 
Web service for a fictional computer consulting service (e.g., p. 4, Classifying the Business 
and p. 6, Defining the Services). As with Rosenberg, Seely does not provide any motivation 
to provision a mobile terminal using Web services because Seely is merely a Web services 
tutorial relating to a fictional business. Although Seely may suggest some general 
advantages of Web services, applying the teaching of Seely to Rosenberg without some 
other motivation is tantamount to applying an impermissible hindsight analysis based on the 
Applicant's teachings. "[I]mpermissible hindsight must be avoided and the legal 
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conclusion must be reached on the basis of the facts gleaned from the prior art." MPEP 
§2142. Applicant respectfully submits that neither Rosenberg, Seely, nor knowledge 
generally available to one of ordinary skill in the art provides facts that would motivate 
combining the reference teachings. Therefore Applicant respectfully submits that a prima 
facie case of obviousness has not been established as to Claims 4-7, and that these claims 
are in condition for allowance. 

Claim 32 stands rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Rosenberg and Seely further in view of U.S. Publication No. 2003/0207685 to Rankin 
(hereinafter Rankin), Applicants respectfully traverse the rejection. The Applicant 
respectfully submits that the combination of Rosenberg and Seely in view of Rankin does 
not teach or suggest all of the limitations of Claim 32. 

Dependent Claim 32 depends from independent Claim 24, and includes all of the 
limitations of the base claim and any intervening claims, and recites additional features 
which further distinguish this claim from the cited references. As argued in greater detail 
above, Rosenberg and Seely at least fail to teach provisioning a mobile terminal by a 
provisioning Web service, because Rosenberg teaches provisioning the terminal manually 
and Seely is silent on provisioning. Thus the combination of Rosenberg and Seely fail to 
anticipate independent Claim 24, and as a result fails to anticipate Claim 32. Rankin fails to 
cure the deficiencies of Rosenberg and Seely. Rankin is directed to delivering user data 
(e.g., music) to mobile users using short-range radio beacons based on stored profiles of the 
individual user (e.g., [0005], [0026], and [0043]). According to Rankin, "[t]he device is 
connectable to said at least one server or service provider" ([0026]), thus it must be 
presumed that the devices in Rankin are already provisioned. Therefore, the teaching of 
Rankin has no relation to provisioning mobile terminals, and as such Rankin does not teach 
provisioning a mobile terminal by a provisioning Web service. For at least this reason, the 
combination of Rosenberg, Seely, and Rankin do not teach each and every element of the 
Applicant's invention, and thus do not support a case of prima facie obviousness. 

In addition, Rankin does not even appear to teach or suggest the features relied upon 
in the Office Action to support the § 103(a) rejection of Claim 32. As noted in the Office 
Action, the combination of Rosenberg and Seely do not disclose determining whether a 
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mobile terminal is not capable of direct delivery receipt by the data object delivery module, 
and if not, to provide an address of the application at the data object delivery module. In 
paragraph [0038] of Rankin relied upon in the Office Action, Rankin merely teaches 
tailoring of network Quality of Service (QoS) depending on stored profiles. In Claims 8, 
17, and 18 or Rankin, also relied upon in the Office Action, Rankin merely teaches 
buffering data targeted for for unavailable terminals. Nowhere does Rankin describe 
providing an address of a data object delivery module if the terminal is not capable of direct 
delivery receipt. Neither tailoring QoS as described in [0038], nor buffering server-side 
data as described in claims 8, 17, and 18 could be reasonably construed as providing an 
address at an application of a data object delivery module. As such, Rankin fails to teach or 
suggest this element of Claim 32, and a prima facie case of obviousness cannot be 
supported. Applicants respectfully submit that Claim 32 is therefore in condition for 
allowance. 

The undersigned attomey of record invites the Examiner to contact him at 651-686- 
6633 (xl 10) to discuss any issues related to this case. 




Steven R. Furik 
Reg. No. 37,830 
Crawford Maunu PLLC 
1270 Northland Drive, Suite 390 
St. Paul, Minnesota 55120 
(651)686-6633 
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